09 - 国外托管网关：Kong · Cloudflare · Azure · Apigee · Vercel · OpenRouter
前置：08 - 云厂商怎么做，本篇延续那套六项能力坐标系。
本篇回答：国外六家托管网关各自强在哪？以及一件 01 篇 没展开的事 —— 聚合器和网关是两个物种，混淆它们是选型时最常见的错误。
一、聚合器与网关的区别
新手最容易踩的坑：把"聚合器"当成"网关"来评估。
| 聚合器 | 网关 | |
|---|---|---|
| 谁和 provider 有合同 | 聚合器 | 你 |
| 你的 API Key 在谁手里 | 不需要你的 key | 你的 key 交给网关 |
| 请求内容谁看得见 | 聚合器全看得见 | 你自己（自建）或网关厂商 |
| 主要价值 | 省事：一个 key 用全世界的模型 | 管控：路由、配额、审计、合规 |
| 典型代表 | OpenRouter | Kong、Cloudflare、LiteLLM |
一句话区分：聚合器帮你"买"模型，网关帮你"管"模型。
很多产品同时做两件事（Cloudflare、Vercel 都提供 BYOK 和托管账单两种模式），但它们的核心价值主张不同。评估时先问自己：我缺的是采购渠道，还是管控能力？
📖 术语：BYOK（Bring Your Own Key） 你把自己在 OpenAI / Anthropic 的密钥配置给网关，账单还是走你和 provider 的合同，网关只赚服务费（或不赚）。反义词是"托管账单"—— 你直接向网关厂商付钱，它去和 provider 结算。 BYOK 模式下你是网关用法；托管账单模式下你是 聚合器用法。 同一个产品，两种关系。
二、Kong：从传统 API 网关演进而来
Kong/kong ★44,001，Apache-2.0，Lua（基于 OpenResty，也就是 Nginx + Lua）。这是全世界装机量最大的开源 API 网关。
Kong 走 AI 这条路的方式是加插件，而不是重写：AI 能力从 Gateway 3.12（2025 年底）开始通过插件形式加入。
真正的转折点是 2026 年 4 月 14 日发布的 AI Gateway 3.14，其中包含了 Kong Agent Gateway。官方公告的描述是：把 LLM、MCP、A2A 三类 AI 流量统一到同一个控制面治理。
3.14 里几项值得注意的能力（来自官方发布）：
| 能力 | 为什么重要 |
|---|---|
| 原生 A2A 流量治理 | Agent 之间互相调用的流量，过去是完全的盲区 |
| Token exchange（令牌交换） | 见下 |
| 基于 scope 的工具过滤 | 不同身份看到不同的工具列表 —— 正是 05 篇 讲的工具级授权 |
| 增强的限流与护栏 | — |
| 支持 Databricks / DeepSeek / vLLM | 支持 vLLM 意味着可以接自建推理集群 |
📖 术语：token exchange（令牌交换） 用户拿着令牌 A 访问 Agent，Agent 需要以用户的名义去访问后端服务，但后端只认令牌 B。令牌交换就是由网关把 A 换成 B，全程不让 Agent 碰到长期 凭证。 这解决的正是 08 篇 里 AWS 用 Credential Provider 解决的那个问题 —— 入站身份和出站身份必须分开，只是解法不同。
Kong 的核心优势是"你本来就在用它"。 如果公司的 API 流量已经跑在 Kong 上，AI 流量走同一套控制面、同一套鉴权和限流策略、同一套可观测，边际成本极低。
它的代价是 Lua。 想写自定义逻辑，你得写 Lua 插件 —— 这在 2026 年是一个不小的人才门槛。
三、Cloudflare AI Gateway
Cloudflare AI Gateway 的产品介绍是标准套路：缓存、限流、可观测、动态路由、护栏、成本控制，通过一个兼容 OpenAI 或 Anthropic 格式的 API 暴露。
但真正有信息量的是它 2026 年的官方更新日志。 我按时间列出来（引自 Cloudflare 官方 changelog）：
| 日期 | 上线了什么 |
|---|---|
| 2026-06-05 | 消费限额：追踪累计美元花费，超预算直接拦截请求；可按模型、provider 或自定义维度设置 |
| 2026-06-12 | User-Agent 日志：能看出流量是哪个 SDK / 库 / 应用发出来的 |
| 2026-08-05 | 身份感知控制：接入 Cloudflare Access，日志、分析、路由、消费控制里直接带上认证用户身份，不需要客户端自己传 user ID |
| 2026-08-05 | User Insights 面板：按 95 分位消费基线检测 异常用量 |
| 2026-08-07 | Workers AI 与 AI Gateway 统一：统一的模型访问与计费路径；用预付费额度调用前沿模型时限额从 20 RPM 提到 50 RPM |
把这五条连起来看，2026 年 Cloudflare 在 AI 网关上做的事几乎全是同一件：搞清楚钱花在谁身上。
不是路由算法，不是协议支持，是成本归因和身份。这和 04 篇 里 LiteLLM 那 4,789 行限流代码指向的是同一个方向 —— 说明这个市场已经过了"能用就行"的阶段，进入了"要能管账"的阶段。
其中身份感知控制这一条特别值得学。自建网关时，"这次请求是哪个用户发的"通常要靠业务方在 header 里传一个 user ID —— 而业务方可以伪造它。Cloudflare 的做法是从自己的 Access（零信任接入层）直接取认证身份，客户端没有机会撒谎。
💡 这个思路可以直接借鉴到自建网关：身份不要从请求体或自定义 header 里取，要从已经过认证的凭证里取。
3.1 如何阅读厂商对比页
搜索"Cloudflare AI Gateway vs X"时，排在前面的常常是竞品自己写的对比页。比如 Vercel 的对比页会说 Cloudflare 的护栏和 DLP 还在 Beta、不提供自动故障转移和按用户成本归因。
这些说法可能是准确的，但它是有立场的一方选出来的那几条。正确的读法是：把这类对比页当作问题清单而不 是结论 —— 拿着"护栏是不是 Beta""有没有自动故障转移"这几个问题，去两家的官方文档里各查一遍。
四、Azure API Management
Azure 的 AI 网关能力做在 API Management（APIM） 这个已有产品里，而不是新开一个产品。
从能力清单上看，它和其他托管网关差别不大。它的真正差异在别处：如果你的模型本来就跑在 Azure OpenAI 上，APIM 和它是同一个身份体系（Entra ID）、同一个网络边界、同一套合规认证。
这一点的分量比功能清单大得多。企业采购 AI 网关时，「过合规」经常是比「功能全」更硬的约束 —— 而"和已有的 Azure 订阅在同一个信任边界内"是一个现成的答案。
代价是标准的托管网关代价：厂商锁定、定制能力受限、规模上去后成本更高。
这里有个通用判断，对四家国内云同样适用：当你的模型、身份系统、合规审计已经在某朵云上时，那朵云自己的网关几乎总是阻力最小的选择 —— 哪怕它的功能清单不是最长的。
五、Apigee：存量 API 转工具
Google 的 Apigee 在这一轮里的打法非常聚焦：零代码从 API 规范生成托管 MCP Server。
你把 Apigee 指向你已有的 API spec，它自动创建一个托管的 MCP Server。
这件事我们已经见过三遍了：
| 厂商 | 叫法 |
|---|---|
| 阿里云 | REST API 转 MCP Server |
| AWS | OpenAPI / Smithy target |
| 腾讯云 | HTTP/gRPC ↔ MCP 双向转换 |
| Apigee | 从 API spec 自动生成托管 MCP Server |
四家云厂商 + 一家 API 管理老牌厂商，全都在做同一件事。 这已经不是趋势判断，是既成事实。
背后的道理值得单独记住：企业里真正有价值的能力，99% 已经以 REST API 的形式存在了。Agent 生态需要的是 MCP。谁能把这两者之间的转换做得最省事，谁就拿到了企业市场的入口。Apigee 的优势在于它手里本来就攥着大量企业的 API 规范。
六、Vercel AI Gateway
Vercel 的定位很清楚：统一 API 访问多家 provider，内置缓存、限流、fallback 路由。
它最鲜明的一条是商业模式：零加价（zero markup），包括 BYOK 请求在内的每个 token 都不加价。
对应的判断：如果你的应用本来就部署在 Vercel 上，这是阻力最小的选择 —— 和上一节 Azure 的逻辑完全一样。如果不在，它相对 Cloudflare 或自建没有决定性优势。
七、OpenRouter：聚合器代表
OpenRouter —— 400+ 模型、70+ provider，2026 年 5 月完成 1.13 亿美元 B 轮融资，纯托管、无自建选项。
按第一节的划分，它是聚合器不是网关。它的价值是：
- 一个 key 打通几百个模型，包括很多你没有渠道直接采购的
- 想试新模型时零接入成本
- 天然的多 provider 冗余
它不能给你的：
- 请求内容不经第三方（合规硬要求时这条就是死结）
- 细粒度的内部多租户和成本归因
- 私有部署模型的接入
最常见也最合理的用法是两者叠加：自建/托管网关放在内部做管控，把 OpenRouter 配成众多 deployment 中的一个 —— 用它兜住长尾模型，主力模型仍然走自己的直连合同。
八、六家横向对比
六家在"可自建程度"与"核心能力方向"两个维度上的分布：
| Kong | Cloudflare | Azure APIM | Apigee | Vercel | OpenRouter | |
|---|---|---|---|---|---|---|
| 物种 | 网关 | 网关（可托管账单） | 网关 | 网关 | 网关（可托管账单） | 聚合器 |
| 开源内核 | ✅ ★44,001 | ❌ | ❌ | ❌ | ❌ | ❌ |
| 能自建 | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| MCP | ✅ | — | — | ✅ 自动生成 | — | — |
| A2A | ✅ 3.14 起 | — | — | — | — | — |
| 最强的一点 | 统一治理 LLM/MCP/A2A | 成本归因与身份 | 与 Azure 同信任边界 | 存量 API 转工具 | 零加价 | 模型覆盖面 |
| 最适合谁 | 已在用 Kong | 边缘 / 全球分布 | 已在用 Azure | 已在用 Apigee | 已在用 Vercel | 需要试遍模型 |
注意最后一行 —— 六家里有四家的最佳适用条件是"你已经在用它"。
这不是巧合，也不是偷懒的结论。它准确反映了 2026 年 AI 网关市场的真实状态：核心能力已经高度同质化，差异主要来自生态位置。
九、08 与 09 两篇的结论
把国内四家和国外六家放在一起，能得到三条对选型真正有用的判断：
1. 先问"我在哪朵云上"，再问"哪家功能强"。 十家里有六家的最优适用条件是"你已经在这个生态里"。跨生态选网关要付出的网络、身份、合规成本，通常吃掉全部功能优势。
2. 只有一家有完整的"自建 ↔ 托管"双向通路。 阿里云 AI 网关 ← → Higress 开源版。如果"能迁走"是硬约束，这是唯一的现成答案；否则就是 Kong 自建，或者本专题 02–05 篇拆的那几个开源项目自己搭。
3. MCP 已经是入 场券，A2A 是下一张。 十家产品里，MCP 支持已经从差异点变成了标配。而 A2A（Agent 之间的流量）目前只有 Kong 和 AWS 明确做了 —— 这是 2026 年下半年这个赛道的实际前沿位置。
下一篇 → 10 - 性能与形态代价：回到自建，看四种形态各要付出什么运行时代价，以及一套可复现的压测方法。
← 回到 专题索引 · Agent Infra 板块总览